It took me a while because of travel and other projects, but I finally released a tar ball containing Debian lenny for the SheevaPlug along with some installation instructions. It should be really easy to install Debian this way, but I'll also make sure that SheevaPlug support will be in the Debian installer for the next release of Debian. For now, check out the tar ball I prepared!

Spring has arrived in Europe and I'm looking forward to spending more time outdoors. While I was pondering some plans, I thought it would be nice to have a GPS. I've never used a GPS before but it seems it will allow me to combine outdoors activities such as walking and hiking with geek things. In particular, I'm interested in tracking where I'm going (what route, what distance, what speed, etc), geotagging photos and possibly contributing to OpenStreetMap. Since last week, I have a Qstarz BT-Q1000X (Travel Recorder X), a GPS logger and receiver, and I've been playing around with it a bit. This device uses the new MTK II chip, which gives good accuracy and long battery time. I've created a new gps category in which I'll share my experience using a GPS in general and specifically the Qstarz BT-Q1000X. I've also created a Qstarz BT-Q1000X and Debian page to describe how to use this GPS device on Linux and I'll add more information to the page as I try out different applications.

What seems like eons ago, I ordered one of those SheevaPlug Development Kits. After about six weeks, they got around to shipping it, and then, yesterday, after I assume a tortoise had piloted it across the country on broken tricycle, it was finally delivered to me. I booted it up, observed that there was some kind of Ubuntu thing on it, and set myself to correct that problem. Within an hour I had managed to lock myself out. Here is something I should have read beforehand. Thanks to Martin Michlmayr, it is now running Debian and allowing me to log in. Here are some steps to follow if you would like to boot Debian off of a USB stick plugged into your Sheevaplug:

• Grab the tarball from http://people.debian.org/~tbm/sheevaplug/lenny/
• Make an ext3 filesystem on the first partition of your USB stick (ext2 will not work with the current image)
• Mount the USB stick's filesystem, unpack the tarball onto it, then unmount
• Plug the USB stick into the SheevaPlug's full-sized USB port
• Plug the SheevaPlug in, and use minicom or your favorite terminal program to console in over the mini-USB port (don't forget that you need to use the ftdi_sio module instead of usbserial; 115200,N,8,1, no flow control)
• Abort the autoboot, and type the following commands:

  setenv mainlineLinux yes
  setenv arcNumber 2097
  saveenv
  reset
  setenv bootargs_root 'root=/dev/sda1 rootdelay=10'
  setenv bootcmd_usb 'usb start; ext2load usb 0:1 0x0800000 /boot/uInitrd; ext2load usb 0:1 0x400000 /boot/uImage'
  setenv bootcmd 'setenv bootargs $(console) $(bootargs_root); run bootcmd_usb; bootm 0x400000 0x0800000'
  saveenv
  run bootcmd
  

That should be all there is to it. Next I'm wondering if SDIO wireless cards work.

I visited Seoul last week to represent the Open Source Initiative (OSI) at an open source conference and to sign a Memorandum of Understanding (MOU) with the Korea Software Copyright Committee (SOCOP). SOCOP organized a conference with the title "Free Open Source Software License Insight Conference", and the international speakers included Brett Smith of the FSF, Brendan Scott of Open Source Law, Michael Cot of RedMonk and myself. From the questions we received, it seems that there is a lot of interest in legal questions related to open source. There were a number of folks from hardware companies that asked specific questions what they could do and couldn't do (e.g. related to including sources for GPL code and properly giving credit for BSD code). I think the conference was a great success. The talks were of high value and we got good questions. The audience was quite mixed, ranging from managers to developers. Even though they had simultaneous translation of the talks, the majority of the people listened in English... this gives me hope that some of these folks will end up becoming involved in the international open source community. SOCOP is working on a number of activities related to open source, including:

• An information portal called OLIS.
• The translation of all OSI approved licenses to Korean.
• The verification of open source code to identify which code uses which license.
• More promotional activities, including workshops and conferences.

The day after the conference, I went to the SOCOP office to sign the MOU between SOCOP and OSI with Mr Yung Bo Koo, the chairman of SOCOP. The MOU says that we'll share knowledge and expertise, help with promotional activities and support each other's activities in other ways. I was delighted to sign the MOU between SOCOP and OSI, and I look forward to a fruitful cooperation between our organizations in the future. It's great to see so much interest and so many activities around open source in the Republic of Korea.

DPL candidacy woes Well, time to face it publicly: I lost and Steve/Luk won, it is as simple as that This post is to:

• congratulate with Steve and Luk for the result, I wish you a happy and fruitful DPL term
• thanks all the people which supported me, in particular:
  • lucas, paravoid, and gismo: my candidacy started as a typical "DebConf joke"; if then it has become a reality is for friends like them insisting (or pretending :-P) I was up to the task. Actually, I'm quite happy about the result, so it was definitely worth trying!
  • all the people which contributed comments for my platform, a list in no particular order follows (in the hope of not having forgot anyone!): madduck, enrico, lucas, tbm, godog, gismo, gregoa, dato, ralf, paravoid, buxy. Thank you guys, my platform would have been much worst without your input.
  • all the people who voted for me (of course!)

All in all, standing for DPL has been worth and interesting no matter the result. Time to get back to my usual Debian duties now ...

Marvell posted some performance patches for ARM that speed up the copy_to_user and clear_user functions which are used to copy data around. I see quite a bit of performance increase with these patches on Orion, and I've prepared a test kernel so you can try them out too. This kernel should be treated as experimental, but I'm looking for testers with Orion-based hardware (e.g. QNAP TS-109, TS-209, and TS-409) who are interested in giving it a go. If your system has a rescue mode (the QNAP devices and the HP mv2120 do), I suggest you first make a backup of your flash. On the QNAP devices, you can do this with: Then edit the file /etc/apt/sources.list and add the following line: Now you can install the new kernel: Please ignore the warning that the package cannot be authenticated. This is because I haven't signed the repository. After the installation of the kernel, reboot and do some tests: Do you see any speedup? Do you see any problems?

My patch for initial kernel support for the QNAP TS-119 and TS-219 Turbo NAS got accepted and will be in 2.6.30. I can run Debian on a USB disk without any problems but there are some issues left (some severe, some cosmetic):

• SATA: there are long timeouts when initializing the disk. In most cases, the disk is eventually recognized but it can take quite some time. I've no idea why those timeouts happen.
• Flash: I can read from flash just fine but writing doesn't work.
• Parsing the MAC address: even though a MAC address is set in u-boot, the QNAP firmware stores the real MAC address in flash (similar to the TS-109 and TS-209). The TS-109/TS-209 code to read the MAC address doesn't work because the flash on the TS-219 is connected in a different way (SPI).
• SATA lights: the activity light doesn't work.

Unfortunately, I've no idea how to resolve these issues. However, the QNAP TS-119 and TS-219 have started shipping so hopefully someone else will investigate these issues.

After integrating Matt Palmer's installer patches for D-Link DNS-323, I have now created installer images based on Debian lenny. They will work both on the D-Link DNS-323 as well as the Conceptronic CH3SNAS. I've also written an installation guide and other information, including how to use the recovery mechanism through the serial console.

Various people were wondering how much power the SheevaPlug consumes exactly. Laurent Guerby, who runs the GCC Compile Farm, posted some data today. According to his measurements with an Energy Monitor 3000, the SheevaPlug uses:

3.1W	just on, Linux booted
3.3W	serial
4.3W	serial + Ethernet
5.4W	serial + Ethernet + 100% CPU
6.0W	serial + Ethernet + USB disk
7.0W	serial + Ethernet + USB disk + 100% CPU

However, these figures should be seen as preliminary and relatively high values since power management for Kirkwood has not been implemented in the kernel yet. In particular, the Kirkwood chip has SATA and PCI-E but they could be turned off since they're not used by the SheevaPlug. This is currently not done in the kernel, so you can expect some improvements in this area.

I received a SheevaPlug this week, an intriguing device that packs incredible power and functionality into a tiny package. As many of you know, I've been doing a lot of work on Debian for the Linksys NSLU2 in the last few years. The NSLU2 is a key reason why ARM has become the third most popular architecture in Debian (after 32 and 64 bit x86), and I believe a main reason is that the NSLU2 is so incredibly cheap. At a price under $100, most people don't think too long and simply buy a device and do something cool with it. The SheevaPlug is being offered at the same price range but offers considerably more. Riku Voipio asked the right question: "What would you do with something approximately 10x more powerful with same prize/size range?" I believe the SheevaPlug is a killer replacement for the NSLU2 and here's why:

• Marvell Kirkwood 6281 CPU at 1.2 GHz with 256 KB L2 cache (compared to a 266 MHz CPU)
• 512 MB RAM (compared to lousy 32 MB)
• 512 MB flash, enough for a basic Debian installation (compared to 8 MB)
• Gigabit Ethernet (compared to 100 Mb) and no proprietary microcode required
• 1x USB and 1x SD (compared to 2x USB: the only advantage the NSLU2 has)
• ... and finally: mini-USB with serial console and JTAG: while Debian on the NSLU2 works well and is stable, we regularly had users whose system would no longer boot and there was no good way to figure out why. The serial console on the SheevaPlug actually allows users to figure out what's going on.

I'm incredibly excited about the SheevaPlug and the first thing I did was to take the device apart and look at the inside. The results can be found in the SheevaPlug image gallery. My next project will be slightly more productive: porting Debian. As I see it, we should support the following three installation variants for the SheevaPlug:

• To an external USB drive or stick.
• To an SD card.
• To the 512 MB flash memory on the device.

The first two should be relatively straight forward, but of course installing to the internal flash memory is particularly interesting given that 512 MB (plus compression) is enough for a basic installation of Debian. Unfortunately, installations to MTD flash are currently not supported in the Debian installer but I hope we can find a volunteer who wants to implement this functionality. My next steps are to put a kernel for the SheevaPlug into the archive and to get a basic installation going. From there we can look at more sophisticated installation options and other functionality.

I received a sample of QNAP's new TS-219 Turbo NAS today. The TS-119 and TS-219 devices are an upgrade to QNAP's TS-109 and TS-209 devices and were announced earlier this month at CeBIT. The new TS-219 uses the same robust case as the TS-209 but offers much more performance:

• Marvell Kirkwood 6281 at 1.2 GHz (instead of Orion 5182 at 500 MHz)
• 512 MB RAM (instead of 128 or 256 MB)
• 16 MB flash (instead of 8 MB)

The numbers I've seen about the Kirkwood CPU suggest that the TS-219 will indeed give a very significant performance boost. So far, the TS-219 looks very nice. My only complaint is that QNAP didn't export the second Ethernet port the Kirkwood chip offers, but I suspect this is because they wanted to stay as close to the original design of the TS-209 as possible. In any case, the TS-219 is a nice machine and I look forward to porting Debian to it. As a first step, this means getting the mainline kernel to run on the device and adding a kernel for Kirkwood to the archive (the latter is needed for a number of other devices based on Kirkwood anyway). Hopefully, the remaining porting work and integration into the Debian installer should be fairly straightforward given that the TS-209 is already supported in Debian. I'm sure I'll find out as I dig into the details... I'll give periodic updates of my progress. In the meantime, I've created an image gallery of the TS-219.

I finally had a chance today to test the patches Matt Palmer created to add D-Link DNS-323 support to the Debian installer. I tested the patches on a Conceptronic CH3SNAS which, from a hardware perspective, is a D-Link DNS-323 (rev B1). I noticed that the firmware image specifies a number for the vendor, so we have to generate different installer images for the D-Link DNS-323 and Conceptronic CH3SNAS. That was easy enough to do and I was able to install Debian without any problems. The next steps are to write an installation guide and other documentation, and to improve the kernel (the power LED is blinking and cannot be changed, and fan control is missing).

Jim Buzbee published an article in SmallNetBuilder a few days before Christmas about installing Debian on the QNAP TS-209. I find the article very well written and balanced, and it makes a good introduction for folks who are interested in installing Debian on NAS devices.

I took some pictures the other day of NAS devices I'm currently working on. They are now available in the QNAP TS-409U and Conceptronic CH3SNAS (aka D-Link DNS-323) image galleries.

We added Debian support for the HP Media Vault mv2120 this summer and it works very well. While this NAS device is easily available in the US, I have unfortunately not been able to find it in Europe so far, which obviously limits the number of people who will run Debian on it. Yesterday I learnt that the mv2120 is sold in Europe under the name HP Media Vault Pro mv5020 (GX666AA). I found some shops in the UK that sell the mv5020 but I assume it's also available in other parts of Europe.

QNAP recently released an upgrade for u-boot, the boot loader used on most QNAP devices, that adds a recovery mode. With this recovery mode, a backup image is requested via TFTP and then written to flash. This is useful in case there are problems during the installation or an upgrade of Debian. While Debian itself works well on QNAP and another NAS devices, we get reports from users every once in a while that their machine stopped booting (either after an upgrade or for no good reason) and it's usually impossible to say why since these devices are headless. The recovery mode allows them to put an image into flash that is known to work or an image of the installer that can be used as a rescue option. Essentially, the recovery mode removes the need for a serial console in many cases. I've added information about the recovery mode for the QNAP TS-109, TS-209 and TS-409/TS-409U, including installation instructions of users already running Debian.

Per Andersson ported the Debian installer to the Kurobox Pro this summer as part of a Google Summer of Code project. Along with Riku Voipio, I acted as Per's mentor and gave him advice while he was trying to figure out all the details that were needed to get Debian running on the device. Since I spent the summer in Israel and didn't have my Kurobox Pro with me, I never performed an installation on my own though. Yesterday I finally found time to play with my Kurobox Pro. Per did a great job and the installation worked without any problems. I also investigated how the recovery mode works and added various new information to my Debian on the Kurobox Pro pages. The Kurobox Pro seems like a nice machine, but I hope we'll add full support for the Linkstation Pro and Live soon since these devices are much more easily available. It shouldn't take too much work since these devices are quite similar to the Kurobox Pro.

My posting about receiving a Conceptronic CH3SNAS a month ago prompted Matt Palmer to work on the installer. Matt did a fantastic job and had patches for everything within a few days: he added support for the revision B of the DNS-323 to the kernel, added code to the kernel so the MAC address is parsed from flash, and added DNS-323 support to various components of the installer. Finally, he wrote a really good porting guide that will hopefully inspire other people to port the installer to more NAS devices. Porting to another Orion based device usually doesn't take much now that we have the infrastructure in place. While Matt's patches came too late for inclusion into the initial release of lenny, the release team seems agreeable to the idea of adding support for the D-Link DNS-323 and Conceptronic CH3SNAS to a stable update of lenny. To this end, the dns323-firmware-tools package which is needed to create proper firmware images for the DNS-323 was accepted for lenny a few days ago. Alan Fletcher also kindly agreed to make a serial cable for me, so hopefully I'll get a chance to test Matt's patches soon and integrate them into the installer. In the meantime, I created a few simple pages about Debian on the D-Link DNS-323 which I will extend once support has been integrated into the installer.

It is often argued that companies have to work with the FOSS community and there are good reasons for doing so. I've tried to collect a number of case stories of good and bad community interaction that may help as a starting point for further exploration of this topic:

• NVidia is probably the best example of a company that is not interested in providing open source drivers for their graphics chips. There are lots of folks who won't buy hardware with NVidia chips for this reason. Intel is the number 1 choice at the moment because they work closely with the community. Related to this, the Linux Foundation and kernel community released a statement regarding open drivers.
• When Sun finally made Java available as open source, they argued that it would help inclusion and distribution of Java (e.g. inclusion into Debian). Sun also felt that the GPL provides the strongest protection "against misbehaviour by monopolists in the Java platform".
• The Novell/Microsoft deal was not perceived well by the community, which led to web sites like http://boycottnovell.com
• Nokia recently had an insightful blog posting about the problems when nobody knows about the open source contributions you make: for example, you cannot influence decisions in a project as easily.
• Sun is often criticized for dominating all open source projects they run. They can be used as a good example that you have to give up some control in order to get outside participation.
• The fact that Xen is not in the mainline kernel is a key reason why a number of companies (e.g. IBM, Red Hat) are looking at KVM (which is in the mainline kernel and actively developed in the community). In fact, "looking" is probably not the best word. IBM is actively working on KVM to make it a viable solution and Red Hat recently acquired Qumranet, the company behind KVM.
• Oracle got fairly bad press for copying the Red Hat distribution and changing Red Hat to Oracle, without engaging in the Red Hat community.
• There's a paper that looks at "empirical evidence on the incentives of firms that engage in OS activities." They look at 146 Italian companies supplying open source solutions, but unfortunately the study doesn't include any major company.

Can you think of other examples? (Originally published on FOSSBazaar where comments are possible)

I started building the Debian archive with GCC 4.4 ten days ago to report build errors. I've completed the archive build now and reported about 220 bugs (the majority with patches). There are roughly 30 build failures left that I haven't analyzed yet. There are also about 35 packages that fail because the boost headers don't work with GCC 4.4. I'll try to build them when the boost headers get fixed. The majority of GCC 4.4 build errors are trivial. The large majority of failures is because of missing #include statements. There are also about 20 build errors because of improved preprocessor checks. I'll try to do another archive build when the gcc-4.4 package is in Debian.